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(54) Compression circuitry for generating an encoded bitstream from a plurality of video frames 



(57) Compression circuitry for generating an encod- 
ed bitstream from a plurality of video frames. Data is 
DCT transformed and then streamed to a processor 
where quantised and inverse quantised blocks are gen- 
erated. A second streaming data connection streams 
the inverse quantised blocks to an inverse DCT block to 



generate reconstructed prediction error macroblocks. 
An addition circuit adds each reconstructed prediction 
error macroblock and its corresponding predictor mac- 
roblockto generate a respective reconstructed macrob- 
lock. The quantised macroblocks are zig-zag scanned, 
run level coded and variable length coded to generate 
an encoded bitstream. 
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Description 

FIELD OF INVENTION 

[0001] The present invention relates to motion picture 
compression circuits for pictures such as television pic- 
tures, and more particularly to a compression circuit 
complying with H.261 and MPEG standards. 

BACKGROUND OF THE INVENTION 

[0002] Figures 1A-1C schematically illustrate three 
methods for compressing motion pictures in accordance 
with H.261 and MPEG standards. According to H.261 
standards, pictures may be of intra or predicted type. 
According to MPEG standards, the pictures can also be 
of bidirectional type. 

[0003] Intra ("I") pictures are not coded with reference 
to any other pictures. Predicted ("P") pictures are coded 
with reference to a past intra or past predicted picture. 
Bidirectional ("B") pictures are coded with reference to 
both a past picture and a following picture. 
[0004] FIG. 1A illustrates the compression of an intra 
picture 11 . Picture 11 is stored in a memory area M1 be- 
fore being processed. The pictures have to be initially 
stored in a memory since they arrive line by line whereas 
they are processed square by square, the size of each 
square being generally 16.times.16 pixels. Thus, before 
starting to process picture 11 , memory area M1 must be 
filled with at least 16 lines. 

[0005] The pixels of a 16.times. 16-pixel square are ar- 
ranged in a so-called "macroblock". A macroblock In- 
eludes four 8. times. 8-pixel luminance blocks and two or 
four 8.times. 8-pixel chrominance blocks. The processes 
hereinafter described are carried out by blocks of 
8.times.8 pixels. 

[0006] The blocks of each macroblock of picture 11 are 
submitted at 1 0 to a discrete cosine transform (DCT) fol- 
lowed at 11 by a quantisation. A DCT transforms a ma- 
trix of pixels (a block) into a matrix whose upper left cor- 
ner coefficient tends to have a relatively high value. The 
other coefficients rapidly decrease as the position 
moves downwards to the right. Quantisation involves di- 
viding the coefficients of the matrix so transformed, such 
that a large number of coefficients which are a distance 
away from the upper left corner are cancelled. 
[0007] At 12, the quantified matrices are subject to 
zigzag scanning (ZZ) and to run/level coding (RLC). Zig- 
zag scanning has the consequence of improving the 
chances of consecutive series of zero coefficients, each 
of which is preceded by a non-zero coefficient. The run/ 
level coding mainly includes replacing each series from 
the ZZ scanning with a pair of values, one representing 
the number of successive zero coefficients and the other 
representing the first following non-zero coefficient. 
[0008] At 1 3, the pairs of values from the RLC are sub- 
ject to variable length coding (VLC) that includes replac- 
ing the more frequent pairs with short codes and replac- 



ing the less frequent pairs with long codes, with the aid 
of correspondence tables defined by the H.261 and 
MPEG standards. The quantification coefficients can be 
varied from one block to the next by multiplication by a 
5 quantisation coefficient. That quantisation coefficient is 
inserted during variable length coding in headers pre- 
ceding the compressed data corresponding to macrob- 
locks. 

[0009] Macroblocks of an intra picture are used to 
10 compress macroblocks of a subsequent picture of pre- 
dicted or bidirectional type. Thus, decoding of a predict- 
ed or bidirectional picture is likely to be achieved from 
a previously decoded intra picture. This previously de- 
coded intra picture does not exactly correspond to the 
is actual picture initially received by the compression cir- 
cuit, since this initial picture is altered by the quantifica- 
tion at 1 1 . Thus, the compression of a predicted or intra 
picture is carried out from a reconstructed intra picture 
11 r rather than from the real intra picture 11 , so that de- 
20 coding is carried out under the same conditions as en- 
coding. 

[0010] The reconstructed intra picture 11 r is stored in 
a memory area M2 and is obtained by subjecting the 
macroblocks provided by the quantification 11 to a re- 

25 verse processing, that is, at 15 an inverse quantification 
followed at 16 by an inverse DCT 
[0011] FIG. 1B illustrates the compression of a pre- 
dicted picture P4. The predicted picture P4 is stored in 
a memory area M1 . A previously processed intra picture 

30 ||r has been reconstructed in a memory area M2. 

[0012] The processing of the macroblocks of the pre- 
dicted picture P4 is carried out from so-called predictor 
macroblocks of the reconstructed picture 11 r. Each mac- 
roblock of picture P4 (reference macroblock) is subject 

35 at 17 to motion estimation (generally, the motion esti- 
mation is carried out only with the four luminance blocks 
of the reference macroblocks) , This motion estimation 
includes searching in a window of picture llrfor a mac- 
roblock that is nearest, or most similar to the reference 

40 macroblock. The nearest macroblock found in the win- 
dow is the predictor macroblock. Its position is deter- 
mined by a motion vector V provided by the motion es- 
timation. The predictor macroblock is subtracted at 18 
from the current reference macroblock. The resulting 

45 difference macroblock is subjected to the process de- 
scribed with relation to FIG. 1A. 

[0013] Like the intra pictures, the predicted pictures 
serve to compress other predicted pictures and bidirec- 
tional pictures. For this purpose, the predicted picture 
50 P4 js reconstructed in a memory area M3 by an inverse 
quantification at 15, inverse DCT at 19, and addition at 
19 of the predictor macroblock that was subtracted at 
18. 

[0014] The vector V provided by the motion estimation 
55 17 js inserted in a header preceding the data provided 
by the variable length coding of the currently processed 
macroblock. 

[0015] FIG. 1C illustrates the compression of a bidi- 
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rectionai picture B2. Bidirectional pictures are provided 
for in MPEG standards only. The processing of the bidi- 
rectional pictures differs from the processing of predict- 
ed pictures in that the motion estimation 17 consists in 
finding two predictor macroblocks in two pictures 11 rand 
P4r, respectively, that were previously reconstructed in 
memory areas M2 and M3. Pictures 11 rand P4r gener- 
ally respectively correspond to a picture preceding the 
bidirectional picture that is currently processed and to a 
picture following the bidirectional picture. 
[001 6] At 20, the mean value of the two obtained pre- 
dictor macroblocks is calculated and is subtracted at 18 
from the currently processed macroblock. 
[0017] The bidirectional picture is not reconstructed 
because it is not used to compress another picture. 
[001 6] The motion estimation 1 7 provides two vectors 
V1 and V2 indicating the respective positions of the two 
predictor macroblocks in pictures 11 r and P4r with re- 
spect to the reference macroblock of the bidirectional 
picture. Vectors V1 and V2 are inserted in a header pre- 
ceding the data provided by the variable length coding 
of the currently processed macroblock. 
[0019] In a predicted picture, an attempt is made to 
find a predictor macroblock for each reference macrob- 
lock. However, in some cases, using the predictor mac- 
roblock that is found may provide a smaller compression 
rate than that obtained by using an unmoved predictor 
macroblock (zero motion vector), or even smaller than 
the simple intra processing of the reference macroblock. 
Thus, depending upon these cases, the reference mac- 
roblock is submitted to either predicted processing with 
the vector that is found, predicted processing with a zero 
vector, or intra processing, 

[0020] In a bidirectional picture, an attempt is made 
to find two predictor macroblocks for each reference 
macroblock. For each of the two predictor macroblocks, 
the process providing the best compression rate is de- 
termined, as indicated above with respect to a predicted 
picture. Thus, depending on the result, the reference 
macroblock is submitted to either bidirectional process- 
ing with the two vectors, predicted processing with only 
one of the vectors, or intra processing. 
[0021] Thus, a predicted picture and a bidirectional 
picture may contain macroblocks of different types. The 
type of a macroblock is also data inserted in a header 
during variable length coding. According to MPEG 
standards, the motion vectors can be defined with an 
accuracy of half a pixel. To search a predictor macrob- 
lock with a non integer vector, first the predictor macrob- 
lock determined by the integer part of this vector is 
fetched, then this macroblock is submitted to so-called 
"haff-pixei filtering", which includes averaging the mac- 
roblock and the same macroblock shifted down and/or 
to the right by one pixel, depending on the integer or 
non-integer values of the two components of the vector. 
According to H.261 standards, the predictor macrob- 
locks may be subjected to low-pass filtering. For this 
purpose, information is provided with the vector, indicat- 



ing whether filtering has to be carried out or not. 
[0022] The succession of types (intra, predicted, bidi- 
rectional) is assigned to the pictures in a predetermined 
way, in a so-called group of pictures (GOP). A GOP gen- 

5 erally begins with an intra picture. It is usual, in a GOP, 
to have a periodical series, starting from the second pic- 
ture, including several successive bidirectional pictures, 
followed by a predicted picture, for example of the form 
IBBPBBPBB ... where I is an intra picture, B a bidirec- 

10 tional picture, and P a predicted picture. The processing 
of each bidirectional picture B is carried out from mac- 
roblocks of the previous intra or predicted picture and 
from macroblocks of the next predicted picture. 
[0023] The various functional blocks that are used in 

is a typical prior art functional implementation are shown 
in Figure 2. For clarity, the motion estimation engine and 
memory for storing macroblocks and video pictures 
have been omitted. 

[0024] In Figure 2, a reference macroblock 200 is sup- 
20 plied to a subtraction circuit 201 .where the predictor 202 
for that macroblock is subtracted (in the case of B and 
P pictures, only). The resultant error block (or the orig- 
inal macroblock, for I pictures) is passed on to a DCT 
block 203, then to a quantisation block 204 for quanti- 
25 sation. 

[0025] The quantised macroblock is forwarded to an 
encoding block 205 and an inverse quantisation block 
206. The encoding block 205 takes the quantised mac- 
roblock and zig-zag encodes it, performs run level cod- 

30 jng on the resultant data, then variable length packs the 
result, outputting the now encoded bitstream. 
[0026] The bitstream is monitored and can be control- 
led via feedback to a rate control system 207. This con- 
trols quantisation (and dequantisation) to meet certain 

35 objective for the bitstream. A typical objective is a max- 
imum bit-rate, although other factors can also be used. 
[0027] The inverse quantisation block 206 in this Fig- 
ure is the start of a reconstruction chain that is used to 
generate a reconstructed version of each frame, so that 

40 the frames the motion prediction engine is searching for 
matching macroblocks are the same as will be regener- 
ated during decoding proper. After inverse quantisation, 
the macroblock is inverse DCT transformed in IDCT 
block 208 and added in an adding block 209 to the orig- 

45 inal predictor used to generate the error macroblock. 
This reconstructed block is stored in memory for subse- 
quent use in the motion estimation process. 
[0028] The various blocks required to generate the 
encoded output stream have different computational re- 

50 quirements, which themselves can vary according to the 
particular application or user selected restrictions. 
Throttling of the output bitstream to meet bandwidth re- 
quirements is typically handled by manipulating the 
quantisation step. 

55 [0029] Pure hardware architectures, while potentially 
the most efficient, suffer from lack of flexibility since they 
can support only a restricted range of standards; more- 
over they have long design/verification cycles. On the 
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other hand, pure software solutions, while being the 
most flexible, require high-performance processors un- 
suited to low-cost consumer applications. 
[0030] It would be desirable to provide an architecture 
that allowed for relatively flexible bitstream control whilst 5 
reducing the amount of software=based processing 
power required. 

SUMMARY OF INVENTION 

w 

[0031] According to a first aspect of the invention, 
there is provided compression circuitry for generating 
an encoded bitstream from a plurality of video frames, 
the circuitry including: 

15 

discrete cosine transform (DOT) circuitry for accept- 
ing prediction error macroblocks and generating 
DCT transformed macroblocks; 
a first streaming data connection for streaming the 
DCT transformed macroblocks from the DCT trans- 20 
formation circuitry to a processor, the processor be- 
ing configured to run software for: 

(i) quantising the DCT transformed macrob- 
locks to generate quantised macroblocks; and 25 

(ii) inverse quantising the quantised macrob- 
locks to generate inverse quantised macrob- 
locks; 

a second streaming data connection for streaming 30 
the inverse quantised macroblocks from the proc- 
essor; 

inverse discrete cosine transform (IDCT) circuitry 
for accepting the streamed inverse quantised mac- 
roblocks and IDCT transforming them to generate 35 
reconstructed prediction error macroblocks; 
an addition circuit for adding each reconstructed 
prediction error macroblock and its corresponding 
predictor macroblock, thereby to generate a re- 
spective reconstructed macroblocks for use in en- 40 
coding of other macroblocks; 
means for zig-zag scanning, run level coding and 
variable length coding the quantised macroblocks 
to generate an encoded bitstream, 

45 

[0032] Preferably, the DCT and IDCT circuitry perform 
DCT and IDCT processing at a rate determined by the 
arrival of data from the relevant data connection. 
[0033] Preferably, the first and second streaming data 
connections are handshake controlled. More preferably, so 
the DCT and IDCT circuitry perform DCT and IDCT 
processing at a rate determined by the handshake con- 
trol signals. 

[0034] In a preferred form, the process or is configured 

to run software for implementing the zig-zag scanning 55 

and run length coding. 

[0035] Preferably, the DCT and IDCT circuitry share 
hardware. It is particularly preferred that the DCT and 



IDCT circuitry comprise a single functional block selec- 
tively operable in a DCT or IDCT mode. 
[0036] In a preferred form, the compression circuitry 
further includes a motion estimation engine for supply- 
ing the predictor macroblocks to the I DCT circuitry. More 
preferably, the motion estimation engine is configured 
to generate the prediction error macroblocks by sub- 
tracting predictor macroblocks from respective corre- 
sponding picture macroblocks of the picture being en- 
coded, and to supply the prediction error macroblocks 
to the DCT circuitry. 

[0037] In a preferred embodiment, the circuitry in- 
cludes a hardware VLC packer and a third streaming 
data connection for streaming the run length coded data 
from the processor to the hardware VLC packer. 
[0036] Preferably, the compression circuitry further in- 
cludes macroblock memory for storing the reconstruct- 
ed macroblocks. 

[0039] It is particularly preferred that the compression 
circuitry can be configured for decoding of a com- 
pressed video stream. 

[0040] in a second aspect, the present invention pro- 
vides a method of generating an encoded bitstream 
from a plurality of video frames, the method including 
the steps of: 

discrete cosine transforming prediction error mac- 
roblocks to generate DCT transformed macrob- 
locks; 

streaming the DCT transformed macroblocks from 
the DCT transformation circuitry to a processor via 
a first streaming data connection; 
in the processor: 

(i) quantising the DCT transformed macrob- 
locks to generate quantised macroblocks; and 

(ii) inverse quantising the quantised macrob- 
locks to generate inverse quantised macrob- 
locks; 

streaming the inverse quantised macroblocks from 
the processor via a second streaming data connec- 
tion; 

inverse discrete cosine transforming (IDCT) the 
streamed inverse quantised macroblocks to gener- 
ate reconstructed prediction error macroblocks; 
adding each reconstructed prediction error macrob- 
lock and its corresponding predictor macroblock, 
thereby to generate a respective reconstructed 
macroblocks for use in encoding of other macrob- 
locks; 

zig-zag scanning, run level coding and variable 
length coding the quantised macroblocks to gener- 
ate an encoded bitstream. 

[0041 ] Preferably, the DCT and IDCT processing take 
place at a rate determined by the arrival of data from the 
relevant data connection. 
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[0042] Preferably, the first and second streaming data 
connections are handshake controlled. More preferably, 
the step of DCT and IDCT processing at a rate deter- 
mined by the handshake control signals. 
[0043] Preferably, the processor is configured to run 
software for implementing the zig-zag scanning and run 
length coding, 

[0044] In a preferred embodiment, the DCT and IDCT 
circuitry share hardware. More preferably, the DCT and 
IDCT circuitry comprise a single functional block selec- 
tively operable in a DCT or IDCT mode. 
[0045] Preferably the method further includes the 
step of receiving, in the IDCT circuitry, the predictor 
macroblocks from a motion estimation engine. More 
preferably, the method includes the step, in the motion 
estimation engine, of generating the prediction error 
macroblocks by subtracting predictor macroblocks from 
respective corresponding picture macroblocks of the 
picture being encoded, and supplying the prediction er- 
ror macroblocks to the DCT circuitry. 
[0046] In a preferred form, the circuitry includes a 
hardware VLC packer, the method including the step of 
streaming the run length coded data from the processor 
to the hardware VLC packer via a third streaming data 
connection. 

[0047] Preferably, the reconstructed macroblocks are 
stored in macroblock memory. 

[0048] In each aspect of the invention, it is preferred 
that the encoded bitstream conforms to MPEG, MPEG- 
2 and/or H.261 standards. 

BRIEF DESCRIPTION OF DRAWINGS 

[0049] 

Figures 1 A to 1 C, described above, illustrate three 
picture compression processes according to H.261 
and MPEG standards; 

Figure 2, described above, is a simplified schematic 
of the functional blocks in atypical MPEG encoding 
scheme, in accordance with the prior art; 

Figure 3 is a schematic of an encoder loop, in ac- 
cordance with the invention; 

Figure 4 is a schematic of compression circuitry for 
generating an encoded bitstream from a plurality of 
video frames, in accordance with the invention, in 
encoding mode; 

DETAILED DESCRIPTION 

[0050] Figure 3 shows an overview of the functional 
blocks of the preferred form of the invention, in which 
hardware functionality is represented by rectangular 
blocks and software functionality is represented by an 
oval block. 



[0051] The functional blocks include an subtraction 
circuit 300 for subtracting each predictor macroblock, as 
supplied by the motion estimation engine (described lat- 
er) from its corresponding picture macroblock, to gen- 

5 erate a prediction error macroblock. For an I picture, 
there is no predictor, so the macroblock is passed 
through the subtraction circuit with no change. 
[0052] The prediction error macroblock is supplied to 
a DCT circuit 301 where a forward discrete cosine trans- 

10 form is performed. Such hardware and its operation are 
well known in the prior art and so have not been de- 
scribed here in further detail. 

[0053] The output of the DCT is streamed to a proc- 
essor 302 (described later) which performs the quanti- 
fy sation, zig-zag coding, a run level coding steps in the 
encoding process. The resultant data is variable length 
coded and output as an encoded bitstream. In the sim- 
plified schematic of Figure 3, the variable length coding 
takes place in software. However, in an alternative em- 
20 bodiment described later, the variable length coding and 
packing, or just packing, is performed in hardware, since 
this provides a drastic increase in performance com- 
pared to software coding running on a general purpose 
processor. 

25 [0054] As well as these steps, the processor also per- 
forms inverse quantisation, and the resultant inverse 
quantised macroblocks are sent to an inverse DCT (ID- 
CT) circuit 303 via a streaming interface. An inverse 
DCT is performed and the resultant reconstructed error 

so macroblock is added to the original predictor macrob- 
lock (for P and B pictures only) by an addition circuit 304. 
The predictor macroblocks have been delayed in a de- 
lay buffer 305. For I and P pictures, the macroblock is 
fully reconstructed after the IDCT circuit. The resultant 

35 reconstructed macroblocks are then stored in memory 
(not shown) for use by the motion estimation engine in 
generating predictors for future macroblocks. This is 
necessary because it is reconstructed macroblocks that 
a decoder will subsequently use to reconstruct the pic- 

^0 tures. 

[0055] Turning to Figure 4, there is shown a more de- 
tailed version of the schematic of Figure 3, and like fea- 
tures are denoted by corresponding reference numer- 
als. In Figure 4, the motion estimation engine 400 for 

45 use with the encoding circuitry is also shown. The mo- 
tion estimation engine 400 determines the best match- 
ing macroblock (or average of two macroblocks) for 
each macroblock in the frame (for B and P pictures only) 
and subtracts it from the macroblock being considered 

50 to generate a predictor error macroblock. The method 
of selecting predictor macroblocks does not form part of 
the present invention and so is not described in greater 
detail herein. 

[0056] The motion estimation engine 400 outputs the 
55 macroblocks, associated predictor macroblocks and 
vectors, and other information such as frame type and 
encoding modes, to DCT/IDCT circuitry via a direct link. 
Alternatively, this information can be transferred over a 
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data bus. Data bus transfer principles are well known 
and so is not described in detail, 

[0057] The DCT and IDCT steps are performed in a 
DCT/IDCT block 401, which includes combined DCT/ 
IDCT circuitry 301/303 that is selectable to perform ei- 5 
ther operation on incoming data. The input is selected 
by way of a multiplexer 402, the operation of which will 
be described in greater detail below. The output of the 
multiplexer is supplied to the delay block 305 and the 
DCT/IDCT circuitry 301/303. Additional data supplied by w 
the motion estimation engine 400, such as the motion 
vector(s), encoding decisions (intra/non-intra, MC/no 
MC, field/frame prediction, field/frame DCT) is routed 
past the delay and DCT/IDCT blocks to a first streaming 
data interface SDI 403. ^ 
[0058] The outputs of the delay block and the DCT/ 
IDCT circuitry are supplied to an addition circuit 304, the 
output of which is sent to memory 450. The output of the 
DCT/IDCT block 301/303 is also supplied to the first SDI 
port 403. 20 
[0059] The first SDI port 403 accepts data from the 
DCT/IDCT block 301/303 and the multiplexer 402 and 
converts it into a format suitable for streaming transmis- 
sion to a corresponding second streaming SDI port 404. 
The streaming is controlled by a handshake arrange- 25 
ment between the respective SDI ports, The second 
streaming SDI port 404 takes the streaming data from 
the first SDI port 403 and converts it back into a format 
suitable for use within the processor 302. 
[0060] Once the data has been transformed back into 30 
a synchronous format, the processor performs quanti- 
sation 405, inverse quantisation 406 and zig-zag/run 
level coding 407 as described previously. It will be ap- 
preciated that the particular implementations of these 
steps in software is now relevant to the present inven- 35 
tion, and so is not described in detail. 
[0061] After inverse quantisation, the macroblock is 
returned to a third SDI port 408, which operates in the 
same way as the first streaming port to convert and 
stream the data to a fourth SDI port 409, which converts <*o 
the data for synchronous use and supplies it to the mul- 
tiplexer 402. 

[0062] The processor 302 outputs the run level coded 
data to a fifth SDI port 41 0, which in a similarfashion to 
the first and third SDI ports, formats the data for stream- *s 
ing transmission to a sixth SDI port 411, which in turn 
reformats the data into a synchronous format. The data 
is then variable length coded and packed in hardware 
VLC circuitry 412. The particular workings of the hard- 
ware VLC packing circuitry 412 are well known in the so 
art, are not critical to the present invention and so will 
not be described in detail. Indeed, as mentioned previ- 
ously, the VLC operation can be performed in software 
by the processor, for a corresponding cost in processor 
cycles. 55 
[0063] It will be appreciated that a number of control 
lines and ancillary detail has been omitted for clarity. For 
example, it is clearthe multiplexer and DCT/IDCT block 
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301/303 need to be controlled to ensure that the correct 
data is being fed to the DCT/IDCT block and that the 
correct operation is being performed. For example, 
when the initial DCT operation 301 is being performed, 
the multiplexer 402 is controlled to provide data from the 
bus (supplied by the motion estimation engine) to the 
DCT/IDCT block 301/303, which is set to DCT mode. 
However, when performing the IDCT operation 303, the 
multiplexer 402 sends data from the fourth SDI port 409 
to the DCT/IDCT block 301/303, which is set to IDCT 
mode. 

[0064] Similarly, some support hardware that would 
exist in the actual implementation has been omitted. An 
obvious example is buffers on the various inputs and 
output It would be usual in such circuitry to include FIFO 
buffers supporting the SDI ports to maximise through- 
put. For the purposes of clarity, such support hardware 
is not explicitly shown. However, it will be understood by 
those skilled in the artto be implicitly present in any prac- 
tical application of the invention. 

[0065] It will be appreciated that, in the encoding 
mode described above, the DCT and IDCT functions of 
the DCT/IDCT block 301/303 will be performed in an in- 
terleaved manner, with one or more DCT operations be- 
ing interleaved with one or more IDCT operations, de- 
pending upon the order of I, P and B pictures being en- 
coded. 

[0066] With slight modifications to control software 
and circuitry, the encoding circuitry described above can 
perform decoding of an encoded MPEG stream. This is 
because the inverse quantisation software and IDCT 
hardware are common to the encoding and decoding 
process. There are at least three ways this can be 
achieved: 

1. If it is only required to offload the IDCT processing 
from the processor, the dequantised coefficient 
blocks can be streamed from the processor to the 
IDCT/DCT block 301/303 via the third and fourth 
SDI ports 408 and 409. The results of the IDCT are 
then read back via the first and second SDI ports 
403 and 404. 

2. Option 1 can be extended to allow more of the 
decoding load to be passed to the DCT/IDCT block 
401 . In particular, the predictor blocks are read into 
the delay buffer 305. The coefficient blocks are then 
read in via the same route by the DCT/IDCT block 
301/303 (in IDCT mode). After the IDCT has taken 
place, the predictor and IDCT processed macrob- 
locks are combined by the addition circuitry 304 and 
written to system memory via the system data bus. 

3. In an alternative to second decoding arrange- 
ment, the motion estimation block is configured to 
provide the predictor blocks to the delay buffer 305 
via the multiplexer 402. The coefficient blocks are 
provided to the DCT/IDCT block 301/303 (in IDCT 
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mode), and the remainder of the procedure is as per 
the second decoding arrangement. 

[0067] Although the invention has been described 
with reference to a number of specific examples, it will s 
be appreciated by those skilled in the art that the inven- 
tion can be embodied in many other forms. 



Claims 10 

1. Compression circuitry for generating an encoded 
bitstream from a plurality of video frames, the cir- 
cuitry including: 

15 

discrete cosine transform (DCT) circuitry for ac- 
cepting prediction error macro-blocks and gen- 
erating DCT transformed macroblocks; 
a first streaming data connection for streaming 
the DCT transformed macroblocks from the 20 
DCT transformation circuitry to a processor, the 
processor being configured to run software for: 

(i) quantising the DCT transformed mac- 
roblocks to generate quantised macrob- 25 
locks; and 

(ii) inverse quantising the quantised mac- 
roblocks to generate inverse quantised 
macroblocks; 

30 

a second streaming data connection for 
streaming the inverse quantised macroblocks 
from the processor; 

inverse discrete cosine transform (I DCT) cir- 
cuitry for accepting the streamed inverse quan- 35 
tised macroblocks and IDCT transforming them 
to generate reconstructed prediction error mac- 
roblocks; 

an addition circuit for adding each reconstruct- 
ed prediction error macroblock and its corre- *o 
sponding predictor macroblock, thereby to gen- 
erate a respective reconstructed macroblocks 
for use in encoding of other macroblocks; 
means for zig-zag scanning, run level coding 
and variable length coding the quantised mac- 45 
roblocks to generate an encoded bitstream. 

2. Compression circuitry according to claim 1 , wherein 
the DCT and IDCT circuitry perform DCT and IDCT 
processing at a rate determined by the arrival of da- 50 
ta from the relevant data connection. 

3. Compression circuitry according to claim 1 or 2, 
wherein the first and second streaming data con- 
nections are handshake controlled. ss 

4. Compression circuitry according to claim 3, wherein 
the DCT and IDCT circuitry perform DCT and IDCT 



processing at a rate determined by the handshake 
control signals. 

5. Compression circuitry according to any one of the 
preceding claims, wherein the processor is config- 
ured to run software for implementing the zig-zag 
scanning and run length coding. 

6. Compression circuitry according to any one of the 
preceding claims, wherein the DCT and IDCT cir- 
cuitry share hardware. 

7. Compression circuitry according to claim 6, wherein 
the DCT and IDCT circuitry comprise a single func- 
tional block selectively operable in a DCT or IDCT 
mode. 

8. Compression circuitry according to any one of the 
preceding claims, further including a motion estima- 
tion engine for supplying the predictor macroblocks 
to the IDCT circuitry. 

9. Compression circuitry according to claim 8, wherein 
the motion estimation engine is configured to gen- 
erate the prediction error macroblocks by subtract- 
ing predictor macroblocks from respective corre- 
sponding picture macroblocks of the picture being 
encoded, and to supply the prediction error macrob- 
locks to the DCT circuitry. 

10. Compression circuitry according to any one of the 
preceding claims, wherein the circuitry includes a 
hardware VLC packer and a third streaming data 
connection for streaming the run length coded data 
from the processor to the hardware VLC packer. 

11. Compression circuitry according to any one of the 
preceding claims, further including macroblock 
memory for storing the reconstructed macroblocks. 

12. Compression circuitry according to any one of the 
preceding claims, configured for decoding of a com- 
pressed video stream. 

13. Compression circuitry according to any one of the 
preceding claims, configured to generate an encod- 
ed bitstream in accordance with MPEG, MPEG-2 
and/or H.261 standards. 

14. A method of generating an encoded bitstream from 
a plurality of video frames, the method including the 
steps of: 

discrete cosine transforming prediction error 
macroblocks to generate DCT transformed 
macroblocks; 

streaming the DCT transformed macroblocks 
from the DCT transformation circuitry to a proc- 
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essor via a first streaming data connection; 
in the processor: 

(i) quantising the DCT transformed mac- 
roblocks to generate quantised macrob- 5 
locks; and 

(ii) inverse quantising the quantised mac- 
roblocks to generate inverse quantised 
macroblocks; 

10 

streaming the inverse quantised macroblocks 
from the processor via a second streaming data 
connection; 

inverse discrete cosine transforming (IDCT)the 
streamed inverse quantised macroblocks to is 
generate reconstructed prediction error mac- 
roblocks; 

adding each reconstructed prediction error 
macroblock and its corresponding predictor 
macroblock, thereby to generate a respective 20 
reconstructed macroblocks for use in encoding 
of other macroblocks; 

zig-zag scanning, run level coding and variable 
length coding the quantised macroblocks to 
generate an encoded bitstream. 25 



15. A method according to claim 14, wherein the DCT 
and IDCT processing take place at a rate deter- 
mined by the arrival of data from the relevant data 
connection. 30 

16. A method according to claim 14 or 15, wherein the 



17. 



18. A method according to any one of claims 14 to 17, 40 
wherein the processor is configured to run software 

for implementing the zig-zag scanning and run 
length coding, 

19. A method according to any one of claims 14 to 18, 45 
wherein the DCT and IDCT circuitry share hard- 
ware. 

20. A method according to claim 19, wherein the DCT 
and IDCT circuitry comprise a single functional 50 
block selectively operable in a DCT or IDCT mode. 

21. A method according to any one of claims 14 to 20, 
further including the step of receiving, in the IDCT 
circuitry, the predictor macroblocks from a motion 55 
estimation engine. 

22. A method according to claim 21 , including the step, 



in the motion estimation engine, of generating the 
prediction error macroblocks by subtracting predic- 
tor macroblocks from respective corresponding pic- 
ture macroblocks of the picture being encoded, and 
supplying the prediction error macroblocks to the 
DCT circuitry. 

23. A method according to any one of claim 14 to 22, 
wherein the circuitry includes a hardware VLC 
packer, the method including the step of streaming 
the run length coded data from the processorto the 
hardware VLC packer via a third streaming data 
connection. 

24. A method according to any one of claims 1 4 to 23, 
wherein the reconstructed macroblocks are stored 
in macroblock memory. 

25. A method according to any one of claims 14 to 24, 
wherein the encoded bitstream conforms to MPEG, 
MPEG-2 and/or H.261 standards. 



A method according to claim 14 or 15, wherein the 
first and second streaming data connections are 
handshake controlled. 

A method according to claim 1 6, including the step 
of DCT and IDCT processing at a rate determined 
by the handshake control signals. 
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